The proliferation of modern electronics into our everyday lives is due in large part to the existence, functionality and relatively low cost of advanced integrated circuits. As technology moves ahead, the sophistication of integrated circuits increases. An important aspect of designing an advanced integrated circuit is the ability to thoroughly test the design of the integrated circuit to assure the design complies with desired architectural, performance, and design parameters. Testing a complex integrated circuit such as a superscalar microprocessor requires the generation of a large number of instruction sequences to assure that the microprocessor behaves properly under a wide variety of circumstances.
Verification techniques generally require automated testing systems that can turn out high volume testcases in an effort to sufficiently cover the realm of possible behaviors of the integrated circuit being tested. Testcases may be generated by a testcase generator in accordance with parameters specified in a file that are provided by a software design specialist or engineer, otherwise the generator generates random testcases.
Verification of microprocessors usually entails the definition of coverage domain(s) for use in measuring the effectiveness of various testcases and testcase generators. These domains are typically static once they are created and are persistent across the entire duration of the verification phase of a development cycle. The resulting coverage information from the testcase is collected and recorded for each entry in these domains and typically kept in a large central database as a cumulative history. These domains are typically a cross-product of various components of the machine state, instructions, and instruction results. For example, where an instruction=“w”, addressing mode(s)=“x”, translation mode(s)=“y”, and resulting condition codes=“z”, the corresponding state space would equal w*x*y*z. As one might suspect, this state space can grow quite large and maintaining records for each state can be memory/compute intensive. Further, adding sequences of events to the coverage domain would expand this state space exponentially.
When using this coverage domain information in a testcase generator employing an internal coverage feedback system for generating “interesting” (e.g., unusual, rare) testcases, maintaining the smallest domain is optimal. It would also be beneficial to generate testcases based only on what has transpired in the current generation session, in addition to referencing the total cumulative coverage history. Other desirable functions include generating a comprehensive test suite, allowing user control over coverage policies, profiling initialization settings, and profiling generation tools.
There may be times when it is desirable to reproduce a testcase that was generated with coverage feedback. One known method of reproducing a testcase is to regenerate all prior testcases 1, 2, . . . , n-1. This is slow and inefficient. When coverage feedback mechanisms are employed in testcase generation, the pseudo-random seed is not the only factor influencing decisions, but can also include the current state of the defined coverage domain element(s). Thus, the coverage state at the time of generating testcase ‘n’ must be reproduced.